闲鱼前端技术体系的背后——魔鱼（良心推荐，从思路到实践）
闲鱼经过近八年的发展，前端技术在整个研发体系中有着举足轻重的地位，前端有迭代速度快，动态化能力强，跨端适配成本低等显著优势。闲鱼前端一直使用淘系提供的基础技术和平台工具，但随着业务的不断发展，逐渐无法满足复杂、个性化的业务和技术环境。
工欲善其事，必先利其器，拥有自己的上层研发体系势在必行，于是从去年下半年开始，前端开始着手代号为「魔鱼」的技术体系建设。
魔鱼
目前魔鱼包含产研平台、研发模式和网关建设三大部分。
产研平台
闲鱼原有的研发流程是在集团提供的工程研发平台上进行的。大致流程如下：
1. 在研发平台创建应用，同步创建Git仓库；
2. 在研发平台创建迭代，同步创建Git分支；
3. 获取分支代码进行本地研发；
4. 提交分支代码，研发平台进行日常/预发构建部署，H5应用构建产物为
CSS/JS/HTML，把HTML文档部署到Web服务器，生成Url进行测试；5. 完成测试，研发平台进行正式发布，给出最终投放Url，并且结束迭代；
可以看到原有的研发流程主要依赖于集团研发平台提供的基本能力，由于平台定位问题，功能相对单一，很多问题还是需要团队自己想办法解决：
问题分析
脚手架及应用配置问题
研发平台提供应用创建引导，帮助初始化应用工程Git仓库和脚手架代码。但是这样创建项目的缺点也非常明显：
1. 只能用于初次创建应用，后续脚手架升级需要配合另外的升级命令或文档。如果在研发过程中对脚手架改动较大，也会对后续的升级造成一定的困难；
2. 大部分情况下，初始化工程并不能直接投入使用，还需要经过一系列手动配置，配置过程对脚手架并不熟悉的新同学来说也是相当痛苦，配置错误会导致项目无法运行，甚至对产品质量和性能造成影响。
页面管理问题
研发平台只关注研发流程，而对应用产物（页面）的管理并不是它的强项。对于闲鱼业务来说，研发构建发布仅仅是开发同学要关心的，业务同学更关心页面的管理及使用，所以衍生出了其他数据投放和管理配置平台，这样的问题是：页面发布和数据配置发布割裂，经常因为两边发布没有同步，导致线上页面和配置不一致造成故障。
解决方案
• 统一模板管理：魔鱼平台集成应用创建及升级功能，预定义工程模板、提供可变配置项，支持创建差异化的工程模板，并且模板和配置后期可以在魔鱼平台进行配置调整及版本升级，彻底告别本地代码维护应用框架的做法。
• 集成配置管理：魔鱼平台提供运营数据配置投放能力，从流程上管控数据配置投放和页面发布，保证线上数据的一致性，实现一站式研发、配置能力。
• 场景管理模式：魔鱼平台提供了业务维度的管理模式，可以把不同应用构建的页面进行圈选，统一管理这些页面的权限、配置及发布，大型活动和部分产品链路都比较适合用这种模式管理多个页面集合。
• 接管发布流程：最终的文档发布和配置数据发布都在魔鱼平台进行，保证了发布流程的一致性，也对定制化研发实现了流程闭环。
补充一个魔鱼平台整体能力图：
研发模式
之前闲鱼的H5业务只有两种研发模式可选：源码开发和模块搭建。复杂逻辑业务和产品链路以源码开发为主；活动和一些二级导购页面以模块搭建为主。随着业务复杂度提高、对性能体验要求的提升，需要扩展研发模式，升级技术方案。
问题分析
产品和运营结合
源码开发的页面一般以产品属性为主，运营很少能介入这类页面的配置和搭建。这类页面如果要配合某些大促活动增加一些运营属性，需要额外的开发工作，并且当活动结束后，还要把这部分代码删除，否则容易产生冗余业务逻辑。
搭建的灵活性与体验性能的平衡
闲鱼一直在使用集团提供的通用搭建平台，它基于一套标准的模块研发管理模式，并且提供整页搭建的能力，但是这个平台并不是为闲鱼量身定制的，很多功能对于闲鱼来说过渡设计，并且由于闲鱼自建商品招选体系，导致在数据投放层面无法跟搭建平台很好地融合，每个模块需要内置数据的获取和处理逻辑，当页面模块数量一多，页面的体验性能会受到较大影响，而且内置业务数据逻辑的模块也很难复用。
解决方案
源码/搭建融合方案
这套方案弥补原有技术能力不足的问题，融合纯源码、源码搭建和纯搭建，开发同学也不再需要做二选一的选择题。
技术方案底层逻辑还是依赖集团的模块体系，这样可以最大限度地利用已有组件物料，同时在模块配置上，引入插槽（Slot）的自定义类型，结合编辑器，实现模块灵活搭建，并且可以嵌套，让模块组合更加灵活。
基于模板的研发模式
以前应用构建的最终产物是 HTML/JS/CSS，现在产研平台接管了应用创建和配置管理等工作，文档具有动态化能力，最终产物是 XTPL/JS/CSS/Schema：
• 其中
XTPL是动态文档模板，线上页面基于它实例化之后可以被CDN缓存；•
Schema是对投放配置数据格式的描述，在平台编辑器解析这份描述文件，渲染出配置表单。
这种研发模式，除了上文提到了平台可以接管页面框架配置以外，还可以基于页面模板创建多个页面实例，实现一码多页，并且每个页面又具有独立的搭投能力，应用的灵活性有了大幅提升。
网关建设
在导购和营销活动、大促场景下，页面数据基于运营配置，数据模型之间又有相互依赖关系，比如运营配置了一组选品id，需要发起二次请求来获取这组选品id下对应的商品数据。
在搭建场景下，模块相对独立，有完整的数据获取及消费逻辑，当多个模块搭建成一个页面之后，每个模块独立处理数据获取和渲染逻辑，导致模块渲染时机不可预期，大量并行的请求也会导致请求阻塞。
问题分析
首屏性能差
由于存在串行数据获取的逻辑，页面渲染时机延后，导致首屏渲染时间较长。解决这类方案一般有以下几种：
1. 服务端胶水层：由服务端把页面依赖的数据合并成一个接口返回，这种仅适合相对稳定的产品业务，对于搭建场景就不可用，而且这类接口没有复用性，由服务端维护胶水层也并不是一个明智的选择；
2. 前端使用SSR直出文档：这种方式相当于由前端接管胶水逻辑，一方面需要基建支持，另一方面无法做页面缓存，对于访问量大的页面，对SSR服务的压力考验也比较大，比较费资源。一些对体验要求高的核心产品页面，SSR确实是一种提升体验性能的王炸，但它还不能作为一个通用技术方案覆盖所有业务场景。
3. 实现一个轻量的网关：处理数据依赖分析、召回、补全、裁切等轻逻辑，这个方案适用于处理通用数据模型，比如商品、内容、用户等，不适用于单一产品数据模型。
组件模块复用率低
由于模块需要负责数据获取逻辑，数据跟业务的耦合度较高，导致开发了很多UI相同，数据依赖不同的模块。这对UI组件复用和维护都不友好。
解决方案
前端数据网关
为了解决首屏数据加载性能问题，针对导购、营销场景，我们采用上面提到的实现一个轻量的网关的方案，顺便联合服务端，对现有闲鱼通用数据模型进行梳理及标准化制定。
动态模板渲染
针对上文提到的动态模板搭建的研发模式，我们接入集团提供的动态模板渲染引擎，当运营在魔鱼平台编辑器完成页面搭建、配置和发布之后，不需要前端介入开发就可以实现模块JS/CSS资源的动态注入，实现文档的动态配置渲染。
补充一个文档和数据消费链路图：
魔鱼现状
将魔鱼率先应用到标准数据模型场景
• 闲鱼业务毕竟是电商App，前端支持的业务中，导购和营销场景比较多，比如「闲鱼优品」、「手机数码」；
• 闲鱼也在不断探索内容场景，比如「会玩」、「圈子」；
无论商品和内容都是相对容易标准化的数据模型，通过数据网关接入后可以快速得到数据性能优化的收益；同时这类业务也是运营参与比较多，利用魔鱼的研发、搭投一体化的体验，提高研发效率和运营配置效率及体验。
业务迁移性能对比
以手机数码频道为例。这个频道在迁移之前，首页主要数据接口有2个，并且是串行依赖关系；迁移到魔鱼之后使用平台数据配置投放，利用网关的数据召回能力，把数据接口合并成1个。
上线后数据：
• 首次内容绘制(FCP)： 673ms --> 1s 这个数据的延长，主要是网关处理原来2个接口的依赖和召回逻辑。
• 跨端首屏(sfsp)： 2502ms --> 1918ms 这个数据的缩短，就是因为省下了端上数据依赖和请求处理的时间。
直观效果对比：
| 改版前 | 改版后 |
未来规划
1. 魔鱼作为前端统一研发体系，不光可以支持H5的研发，后面还可以支持端外小程序、高性能容器的业务开发，提供丰富的研发模板类型，配合组件物料实现页面快速创建；
2. 前端跟服务端紧密结合，除了进行标准化数据模型定义之外，还会接入更丰富的投放配置能力，比如人群定投、AB实验等动态投放策略；
3. 跟招商、权益、测试、埋点/监控等平台进行数据互通和工作流关联，降低多平台之间的流程操作成本。
4. 基于Schema的描述模型和配置编辑器可以作为衍生产品，给闲鱼其他的中后台系统使用，统一闲鱼的数据投放方案。